home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11336 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: library.erc.clarkson.edu!rpi!not-for-mail
  2. From: rmartin@oma.com (Robert C. Martin)
  3. Newsgroups: comp.lang.c++.moderated,comp.object,comp.lang.c++
  4. Subject: Re: how many classes are too much? trying to follow Robert Martin's advice
  5. Date: 13 Mar 1996 17:57:45 -0000
  6. Organization: Object Mentor
  7. Sender: cppmods@netlab.cs.rpi.edu
  8. Approved: Dietmar.Kuehl@uni-konstanz.de
  9. Message-ID: <4i72ap$2fo@netlab.cs.rpi.edu>
  10. References: <4hn86s$im4@netlab.cs.rpi.edu> <4i1fim$bm5@netlab.cs.rpi.edu>
  11.     <4i3vlj$jcs@netlab.cs.rpi.edu>
  12. NNTP-Posting-Host: netlab.cs.rpi.edu
  13. X-Original-Date: 13 Mar 1996 17:14:38 GMT
  14.  
  15.  
  16. rmartin said:
  17.    : The experienced designer does not proliferate classes on a whim.  He
  18.    : does *exactly* what you have done.  He starts with a few classes, and
  19.    : then partition them according to their convenient abstractions.  
  20.  
  21. In article <4i3vlj$jcs@netlab.cs.rpi.edu> ell@access4.digex.net (Ell) writes:
  22.    Should the developer partition according to "convenient abstractions"  for
  23.    "a few classes", gained at one phase of project iteration, and
  24.    incrementation or according to the overall architecture of the project
  25.    based on analysis vocabulary? 
  26.  
  27. Clearly one wants to begin with classes discovered from an analysis of
  28. the problem domain.   
  29.  
  30.    : each partitioning, the designer ensures that the resultant code is
  31.    : simpler and more resilient to change. 
  32.  
  33.    : You saw me do this in my book.  In almost every case I would start
  34.    : with just a few simple core abstractions, and then I would hunt for
  35.    : the underlying abstractions that would allow me to partition the
  36.    : design to my advantage.
  37.  
  38.    How are underlying abstractions different from and more 
  39.    important than domain vocabulary abstractions?
  40.  
  41. They are identical with domain abstractions.  However, they are
  42. *abstractions*.  Often the problem domain vocabulary leads to classes
  43. that are specific to the particular problem.  In many cases,
  44. underlying abstractions can be found that encompass more than just the
  45. particular problem being solved.  Very often these underlying
  46. abstractions are found during subsequent iterations of the development
  47. cycle.  
  48.  
  49.  
  50. --
  51. Robert Martin       | Design Consulting   | Training courses offered:
  52. Object Mentor Assoc.| rmartin@oma.com     |   OOA/D, C++, Advanced OO
  53. 14619 N. Somerset Cr| Tel: (847) 918-1004 |   Mgt. Overview of OOT
  54. Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
  55.  
  56.  
  57.       [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
  58.       [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
  59.       [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
  60.       [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]
  61.